pharos
An introduction to pharos is available in many formats: video, wikipedia and it was even honored by many artists like this painting by Micheal Turner.
More seriously, pharos is a small observer library that let's you create futures 0.3 streams that observers can listen to.
I created it to leverage interoperability we can create by using async Stream and Sink from the futures library. So you can use all stream combinators, forward it into Sinks and so on.
Minimal rustc version: 1.39.
Table of Contents
Security
The main issue with this crate right now is the possibility for the observable to outpace the observer. When using bounded channels, there is back pressure, which might allow DDOS attacks if using the pattern on arriving network packets. When using the unbounded channels, it might lead to excessive memory consumption if observers are outpaced.
TODO: To mitigate these problems effectively, I will add a ring channel where the channel will only buffer a certain amount events and will overwrite the oldest event instead of blocking the sender when the buffer is full.
This crate has: #![ forbid( unsafe_code ) ]
, but it's dependency (futures library) uses a lot of unsafe code.
Limitations
- only bounded and unbounded channel as back-end (for now)
- [
Events
] is not clonable right now (would require support from the channels we use as back-ends, eg. broadcast type channel) - performance tweaking still needs to be done
Future work
Please check out the todo for ambitions.
Install
With cargo add:
cargo add pharos
With cargo yaml:
dependencies:
pharos: ^0.5
With raw Cargo.toml
[]
= "0.5"
Upgrade
Please check out the changelog when upgrading.
Dependencies
This crate only has but one dependency. Cargo will automatically handle it for you. This dependency contains unsafe
code.
dependencies:
futures:
Usage
pharos
only works from async code, implementing Sink to notify observers. You can notify observers from within
poll_*
methods by calling the poll methods of the Sink impl directly. In async context you can use SinkExt::send. Observers must consume the messages fast enough, otherwise they will slow down the observable (bounded channel) or cause memory leak (unbounded channel).
Whenever observers want to unsubscribe, they can just drop the stream or call close
on it. If you are an observable and you want to notify observers that no more messages will follow, just drop the pharos object. Failing that, create an event type that signifies EOF and send that to observers.
Your event type will be cloned once for each observer, so you might want to put it in an Arc if it's bigger than 2 pointer sizes (eg. there's no point putting an enum without data in an Arc).
When you need to notify a pharos object from several async tasks, you can use [SharedPharos
]. This type allows observing and notifying with a shared reference and handles synchronyzation internally.
Examples can be found in the examples directory. Here is the most basic one:
use
;
// here we put a pharos object on our struct
//
// Event types need to implement clone, but you can wrap them in Arc if not. Also they will be
// cloned, so if you will have several observers and big event data, putting them in an Arc is
// definitely best. It has no benefit to put a simple dataless enum in an Arc though.
//
//
// This is the needed implementation of Observable. We might one day have a derive for this,
// but it's not so interesting, since you always have to point it to your pharos object,
// and when you want to be observable over several types of events, you might want to keep
// pharos in a hashmap over type_id, and a derive would quickly become a mess.
//
//
async
Filter
Sometimes you are not interested in all event types an observable can emit. A common use case is only listening for a close event on a network connection. The observe method takes options which let you set the predicate. You can only set one predicate for a given observer.
use *;
//
//
async
API
API documentation can be found on docs.rs.
Contributing
Please check out the contribution guidelines.
Code of conduct
Any of the behaviors described in point 4 "Unacceptable Behavior" of the Citizens Code of Conduct are not welcome here and might get you banned. If anyone including maintainers and moderators of the project fail to respect these/your limits, you are entitled to call them out.